docs(rfd): prompt queueing RFD#484
docs(rfd): prompt queueing RFD#484SteffenDE wants to merge 1 commit intoagentclientprotocol:mainfrom
Conversation
|
Ok, so for Claude we actually can find out when the SDK processed the message by passing |
This basically implements the pending prompt queueing RFD. When a prompt request is received while the agent is already generating, we immediately forward the message to Claude and then wait until it replays the message back to us. When it replays it, we respond to the previous prompt request with "end_turn", which also singifies to the client that the message is now being processed by the agent. See agentclientprotocol/agent-client-protocol#484.
This basically implements the pending prompt queueing RFD. When a prompt request is received while the agent is already generating, we immediately forward the message to Claude and then wait until it replays the message back to us. When it replays it, we respond to the previous prompt request with "end_turn", which also singifies to the client that the message is now being processed by the agent. See agentclientprotocol/agent-client-protocol#484.
This basically implements the pending prompt queueing RFD. When a prompt request is received while the agent is already generating, we immediately forward the message to Claude and then wait until it replays the message back to us. When it replays it, we respond to the previous prompt request with "end_turn", which also singifies to the client that the message is now being processed by the agent. See agentclientprotocol/agent-client-protocol#484.
This basically implements the pending prompt queueing RFD. When a prompt request is received while the agent is already generating, we immediately forward the message to Claude and then wait until it replays the message back to us. When it replays it, we respond to the previous prompt request with "end_turn", which also singifies to the client that the message is now being processed by the agent. See agentclientprotocol/agent-client-protocol#484.
|
|
||
| > How do things work today and what problems does this cause? Why would we change things? | ||
|
|
||
| Today, the specification does not mention what should happen when sending a concurrent prompt request. |
There was a problem hiding this comment.
A few thoughts on this that make it tricky:
- There is a common UX to be able to edit a queued message, how do we handle this?
- what does the response on of the /prompt request "respond" to? the second, queued message?
As an FYI, I am planning to propose soon a completely notification-based turn lifecycle (bidirectional stream of events from both sides updating the session) that will hopefully make it easier to model this sort of thing
There was a problem hiding this comment.
I am happy to wait for a better proposal. This is more of a band-aid solution for sure. It does not allow editing a sent message in any way. Maybe queued is actually the wrong word, since as soon as the prompt is sent, it is assumed to be processed by the agent in some way.
There are two responses:
- The initial prompt responds as soon as the second prompt enters the agent context.
- The second prompt responds when it is done as usual.
A frequently requested feature for Tidewave is the ability to queue prompts like in Claude Code CLI. This is my idea of how that could work.
Now the problem with this is that I tried to find a way to actually get the Claude Agent SDK to tell me when the queued message is inserted into the context, but it looks like there is no way. The message is immediately pulled from the AsyncInterable and the generator does not include any hint when to inject it into a chat view...
I guess one way to cheat would be to just insert it whenever all pending tool results are done. Maybe that's what Claude Code does.